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Abstract 

We  exhibit  programs  that  illustrate  the  power  of  Lisp  as  a  language 
for  expressing  the  design  and  organization  of  computational  systems. 

The  examples  are  chosen  to  highlight  the  importance  of  abstraction 
in  program  design  and  to  draw  attention  to  the  use  of  procedures  to 
express  abstractions^ 

s'' 

Just  as  everyday  thoughts  are  expressed  in  natural  language,  and  formal 
deductions  are  expressed  in  mathematical  language,  methodological  thoughts 
are  expressed  in  programming  languages.  A  programming  language  is  a 
medium  for  communicating  methods,  not  just  a  means  for  getting  a  computer 
to  perform  operations — programs  are  written  for  people  to  read  as  much  as 
v  they  are  written  for  machines  to  execute. 

This  article  exhibits  programs  that  illustrate  the  power  of  Lisp  as  a  lan¬ 
guage  for  expressing  the  design  and  organization  of  computational  systems. 
The  examples  are  chosen  to  highlight  the  importance  of  abstraction  in  pro¬ 
gram  design  and  to  draw  attention  to  the  use  of  procedures  to  express  abstrac¬ 
tions.  Any  programming  language  provides  primitive  components,  means  by 
which  these  can  be  combined,  and  means  by  which  patterns  of  combination 
can  be  named  and  manipulated  as  if  they  were  primitive.  With  appropriate 
abstractions  to  separate  the  specification  of  components  from  the  details  of 
their  implementation  we  can  provide  a  library  of  standard  components  that 
can  be  freely  interconnected,  allowing  great  flexibility  in  design.^- - 

A  language  for  design  should  not  unnecessarily  limit  our  ability  to  make 
abstractions.  Most  traditional  programming  languages,  however,  place  ar¬ 
bitrary  restrictions  on  procedural  abstractions.  Three  common  restrictions 
are:  (1)  requiring  that  a  procedure  be  named  and  then  referred  to  by  name, 


rather  than  stating  its  definition  at  the  point  of  reference;  (2)  forbidding 
procedures  to  be  returned  as  the  values  of  other  procedures;  (3)  forbidding 
procedures  to  be  components  of  such  data  structures  as  records  or  arrays. 

The  well- publicized  programming  methodology  of  top-down,  structured 
design  produces  systems  that  are  organized  as  trees.  Following  (his  method¬ 
ology,  a  system  is  designed  as  a  predetermined  combination  of  parts  that  have 
been  carefully  specified  to  be  combined  as  determined.  Each  of  the  parts  is 
itself  designed  separately  by  this  same  process.  The  methodology  is  flawed: 
if  a  system  is  to  be  robust  it  must  have  more  generality  than  is  needed  for 
the  particular  application.  The  means  for  combining  the  parts  must  allow 
for  after-the-fact  changes  in  the  design  plan  as  bugs  are  discovered  and  as 
requirements  change.  It  must  be  easy  to  substitute  parts  for  one  another  and 
to  vary  the  arrangement  by  which  parts  are  combined.  This  is  necessary  so 
that  small  changes  in  the  problem  to  be  solved  can  be  effected  by  making 
small  changes  in  the  design. 

To  this  end  expert  engineers  stratify  complex  designs.  Each  level  is  con¬ 
structed  as  a  stylized  combination  of  interchangeable  parts  that  are  regarded 
as  primitive  at  that  level.  The  parts  constructed  at  each  level  are  used  as 
primitives  at  the  next  level.  Each  level  of  a  stratified  design  may  be  thought 
of  as  a  specialized  language  with  a  variety  of  primitives  and  means  of  combi¬ 
nation  appropriate  to  that  level  of  detail.  For  example,  in  electrical  design, 
resistors  and  transistors  are  combined  as  analog  circuits  to  make  TTL,  a 
language  appropriate  to  digital  circuits.  TTL  parts  are  in  turn  combined  to 
build  processors,  bus  structures,  and  memory  systems  appropriate  to  com¬ 
puter  architecture.  The  real  power  of  Lisp  is  that  its  unrestricted  abstractions 
support  the  construction  of  new  languages,  greatly  facilitating  the  strategy 
of  stratified  design. 

The  programs  in  this  article  are  written  in  the  Scheme  dialect  of  Lisp. 
Scheme  is  an  especially  good  vehicle  for  exhibiting  the  power  of  procedural 
abstractions  because,  to  a  greater  extent  than  other  Lisp  dialects.  Scheme 
does  not  distinguish  between  patterns  that  abstract  over  procedures  and 
patterns  that  abstract  over  other  kinds  of  data. 


1  Expressing  abstractions  as  procedures 


Procedural  abstractions  can  help  elucidate  a  process  by  allowing  us  to  express 
it  as  an  instance  of  a  more  general  idea.  Consider  the  simple  square  root 
program  of  figure  1 .  The  algorithm  here  is  implemented  in  a  straightforward 
way — the  internal  procedure  try  is  iterated  to  repeatedly  improve  a  guess 
for  the  square  root  until  the  guess  is  good  enough. 

Although  the  square-root  implementation  is  straightforward,  it  does  not 
express  the  underlying  idea  in  generalizable  form.  It  is  not  built  out  of 
components  that  can  be  easily  isolated  for  use  in  solving  other  problems.  A 
clearer  way  to  formulate  the  algorithm  is  as  a  process  of  computing  a  fixed 
point :  the  square  root  of  a  radicand  x  is  the  number  y  such  that  y  =  xjy  or, 
in  other  words,  y  is  a  fixed  point  of  the  procedure 

(lambda  (y)  (/  x  y)) 

How  do  we  find  a  fixed  point  of  a  function?  In  favorable  cases,  we  can 
iterate  the  function  until  the  result  is  close  to  the  input.  For  example,  during 
boring  meetings  many  of  us  have  noticed  that  we  can  find  the  fixed-point 
of  the  cosine  function  by  entering  1  on  a  pocket  calculator  and  repeatedly 
pressing  the  cosine  button.  After  a  while  the  calculated  value  converges  to 
approximately  .739085.  We  can  capture  that  general  idea  as  the  fixed-point 
procedure  shown  in  figure  2.  Fixed-point,  given  a  one-argument  procedure 
f  and  an  initial  value,  keeps  applying  f  until  successive  values  are  close  to 
each  other. 

We  can  attempt  to  find  square  roots  by 
(define  (sqrt  x) 

(fixed-point  (lambda  (y)  (/  x  y))  1)) 

Unfortunately,  this  doesn’t  work.  Unlike  the  cosine  function,  applying  the 
indicated  procedure  over  and  over  does  not  converge  to  a  fixed  point,  but 
rather  alternates  between  the  same  two  values,  which  are  on  opposite  sides 
of  the  square  root. 

In  situations  like  this  we  can  often  force  convergence  by  averaging.  The 
average-damp  procedure  shown  in  figure  3  takes  as  its  argument  a  proce¬ 
dure  that  computes  a  function  /  and  returns  as  its  result  a  procedure  that 
computes  a  function  with  the  same  fixed  point  as  /,  but  whose  oscillations 
are  damped  out  by  averaging  successive  values.  Figure  3  also  shows  how  to 


use  average-damp  to  express  the  square  root  method  as  a  process  of  finding 
the  fixed  point  of  an  average-damped  function. 

The  advantage  of  this  formulation  is  that  it  decomposes  the  method  into 
useful  pieces — finding  fixed-points  of  general  functions  and  using  damping 
to  encourage  convergence.  These  ideas  are  formalized  as  procedural  abstrac¬ 
tions,  identifiable  units  that  are  available  to  be  used  in  other  contexts. 

2  Stratified  design 

Peter  Henderson  [5]  used  stratified  design  in  a  beautiful  analysis  of  the  con¬ 
struction  of  the  “Square  Limit”  woodcut  of  M.  C.  Escher.  He  created  a 
sequence  of  languages  that  makes  it  easy  to  describe  such  images.  There  is 
a  language  of  primitive  pictures  that  are  constructed  from  points  and  lines. 
Built  on  top  of  this  is  a  language  of  geometric  combination  that  describes  how 
pictures  are  placed  relative  to  one  another  to  make  compound  pictures.  Built 
on  this  is  a  language  that  abstracts  common  patterns  of  picture  combination. 

In  Henderson’s  system,  a  picture  is  represented  by  a  picture-drawing  pro¬ 
cedure  that  takes  a  rectangle  and  draws  an  image  scaled  to  fit  the  rectangle. 
At  the  lowest  level  of  description,  a  picture-drawing  procedure  can  be  gen¬ 
erated  beginning  with  a  collection  of  geometric  elements  specified  in  terms 
of  (x,j/)  coordinates  with  respect  to  the  unit  square  (0<x<l;0<y<l). 
Figure  4  shows  two  simple  pictures,  diamond  and  leg,  each  constructed  from 
a  set  of  line  segments  by  the  procedure  primitive-picture.  Besides  seg¬ 
ments,  other  picture  elements  appropriate  to  this  level  are  circles  with  spec¬ 
ified  radii  and  centers,  spline  curves  through  designated  points,  and  so  on. 

The  primitive-picture  procedure  itself  (figure  5)  takes  a  list  of  line 
segments  and  returns  the  corresponding  picture-drawing  procedure.  For  any 
rectangle,  the  scaling  and  shifting  required  to  transform  geometric  elements 
to  fit  the  rectangle  can  be  described  by  an  affine  transformation  on  points 
in  the  plane  that  maps  the  unit  square  to  the  rectangle.  The  point-map 
procedure  shown  in  figure  6  takes  a  rectangle  and  returns  the  appropriate 
transformation  for  that  rectangle. 

The  next  level  of  description  in  Henderson’s  system  is  a  language  of  ge¬ 
ometric  combinators  that  place  pictures  beside  or  above  one  another  and 
rotate  pictures  through  multiples  of  1)0  degrees.  For  instance,  the  beside 


combinator  illustrated  in  figure  7  adjoins  two  pictures  horizontally  so  that 
their  widths  are  in  a  given  ratio. 

One  important  feature  of  Henderson’s  geometric  combinators  is  that  the 
set  of  all  pictures  is  closed  under  combination:  The  beside  of  two  pictures  is 
itself  a  picture  and  can  therefore  be  further  combined  with  other  pictures.  In 
addition,  combinators  can  be  abstracted:  We  can  express  common  patterns 
of  picture  combination  as  new  picture  combinators  defined  in  terms  of  other 
combinators.  For  example,  a  triangle  combination  is  formed  by  placing  one 
picture  above  two  copies  of  another  as  shown  in  figure  8.  Since  combinators 
are  expressed  procedurally,  we  have  all  the  power  of  Lisp  at  our  disposal 
in  defining  complex  combinators.  Figure  9  shows  the  recursive  combinator 
right-push.  The  combinator  language  derives  its  power  from  the  closure 
and  abstraction  properties  of  the  combinators.  That  is  why  it  can  describe 
seemingly  complex  figures  using  only  a  few  simple  ideas. 

The  combinators  themselves  are  manipulated  at  a  third  linguistic  level 
that  describes  common  patterns  of  combining  picture  combinators.  Just  as 
the  square  root  algorithm  above  is  elucidated  by  expressing  it  as  a  fixed-point 
computation,  right-push  can  be  re-expressed  as  an  instance  of  a  general 
pattern  of  “pushing” — repeatedly  applying  a  combinator: 

(define  right-push  (push  beside}) 

Figure  10  shows  how  to  define  push  as  a  procedure  that  transforms  combina¬ 
tors  to  combinators.  Having  isolated  the  push  abstraction,  we  can  apply  it 
to  other  combinators  such  as  triangle,  and  we  can  use  the  resulting  derived 
combinators  to  produce  simple,  stratified  descriptions  of  complex  pictures, 
such  as  the  one  in  figure  10. 

The  stratified  description  of  the  picture  in  figure  10  is  flexible.  We  can 
vary  the  pieces  at  any  level:  We  can  change  the  location  of  a  point  in  the 
primitive  picture  leg,  we  can  replace  the  compound  picture  animal  by  some 
other  basic  repeated  unit,  we  can  replace  triangle  by  some  other  combin- 
tor  to  be  pushed,  or  we  can  replace  push  by  some  other  transformation  of 
combinators. 


3  Metalinguistic  abstractions 


Procedural  abstractions  are  a  source  of  power  in  creating  stratified  designs — 
we  build  structures  by  composing  procedures,  we  abstract  common  patterns 
of  usage,  and  we  build  upon  this  framework.  But  for  some  problems  the  ap¬ 
propriate  means  of  combination  may  be  awkward  to  express  as  compositions 
of  procedures;  towers  of  abstractions  may  not  suffice. 

The  natural  programming  style  for  Lisp  is  functional— the  structural  units 
are  single-valued  functions  implemented  by  procedures.  Within  this  style, 
Lisp  accommodates  object-oriented  programming  and  imperative  program¬ 
ming.  Traditional  algorithmic  languages  such  as  Pascal,  C,  and  FORTRAN 
are  more  naturally  imperative — the  statements  and  the  subroutines  we  build 
modify  the  memory  of  an  abstract  machine.  In  a  logic  programming  language 
such  as  Prolog  the  natural  structural  units  are  (multi-valued)  relations  rather 
than  (single- valued)  functions  or  imperative  operations.  In  simulation  or 
artificial-intelligence  applications  it  is  natural  to  describe  processes  in  event- 
driven  style  by  specifying  collections  of  rules  that  correspond  to  conditions 
or  goals.  Each  of  these  programming  paradigms  is  legitimate,  but  no  sin¬ 
gle  paradigm  is  sufficient — large  systems  typically  have  some  parts  that  are 
naturally  described  using  one  style  and  other  parts  that  are  more  naturally 
expressed  in  other  ways. 

Part  of  the  wonder  of  computation  is  that  we  have  the  freedom  to  change 
the  framework  by  which  the  descriptions  of  processes  are  combined.  If  we 
can  precisely  describe  a  system  in  any  well-defined  notation,  then  we  can 
build  an  interpreter  to  execute  programs  expressed  in  the  new  notation,  or 
we  can  build  a  compiler  to  translate  programs  expressed  in  the  new  notation 
into  any  other  programming  language. 

When  we  design  a  system  that  incorporates  an  application  language,  we 
must  address  metalinguistic  issues  as  well  as  linguistic  issues.  That  is  to 
say,  we  must  consider  not  only  how  to  describe  a  process,  but  also  how  to 
describe  the  language  in  which  the  process  is  to  be  described.  We  must  view 
our  programs  from  two  perspectives:  From  the  perspective  of  the  interpreter 
or  compiler,  an  application  program  is  merely  data,  and  the  interpreter  or 
compiler  operates  on  that  data  without  reference  to  what  the  program  is 
intended  to  express.  When  we  write  programs  in  the  application  language, 
we  view  that  same  data  as  a  program  with  meaning  in  the  application  domain. 
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Interpreters  and  compilers  are  just  programs,  but  they  are  special  pro¬ 
grams.  An  application  program  to  be  interpreted  or  compiled  is  not  a  compo¬ 
sition  of  abstractions  of  the  language  in  which  the  interpreter  is  implemented 
or  to  which  the  compiler  translates.  This  linguistic  shift  transcends  the  limits 
of  abstraction. 

One  can  implement  interpreters  and  compilers  in  any  programming  lan¬ 
guage,  but  Lisp’s  facility  with  symbolic  data  provides  unusually  good  support 
for  developing  such  subsystems.  The  Lisp  community  regards  metalinguistic 
abstraction  as  a  standard  programming  technique.  Almost  every  large  Lisp 
program  includes  interpreters  and  compilers  for  several  specialized  languages, 
each  tailored  to  a  specific  part  of  the  application  problem. 

3.1  A  rule  language 

Consider  the  problem  of  simplifying  algebraic  expressions.  For  example,  it 
should  be  possible  to  simplify 

( x  +  sin(xy))  (sin(xj/)  —  x)  +  cos(xy)  cos(yx) 

to  1  —  x2.  The  simplification  process  may  be  captured  as  a  collection  of 
rules  and  a  strategy  for  applying  them.  The  rules  embody  the  commutative 
and  distributive  laws,  various  trigonometric  identities,  and  so  on.  Each  rule 
describes  how  to  reduce  expressions  of  a  certain  form  to  simpler  equivalent 
expressions.  Given  an  expression,  one  finds  an  applicable  rule,  transforms 
the  expression  accordingly,  and  then  attempts  to  simplify  the  transformed 
expression.  The  process  continues  until  one  reaches  an  expression  to  which 
no  rules  apply. 

Figure  1 1  shows  some  algebraic-simplification  rules  written  in  a  language 
that  was  designed  specifically  for  implementing  simplifiers.  A  rule  in  the 
language  has  three  parts:  a  pattern ,  some  extra  conditions,  and  a  skeleton. 
The  pattern  specifies  the  classjof  expressions  to  which  the  rule  is  applicable. 
Patterns  may  contain  constant  terms  and  pattern  variables  that  indicate  ei¬ 
ther  individual  elements  or  arbitrary  segments — sequences  of  zero  or  more 
elements — that  can  appear  at  designated  positions  in  the  expression.  One 
can  also  use  pattern-variable  predicates  to  restrict  the  range  of  values  of  an 
element  or  segment.  A  rule  is  applicable  to  an  expression  if  the  rule  pattern 
matches  a  subexpression  and  if  the  extra  conditions  are  satisfied.  The  result 
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of  a  rule  application  is  the  original  expression  with  the  matched  subexpres¬ 
sion  replaced  by  the  instantiated  rule  skeleton.  The  instantiated  skeleton  is 
formed  by  substituting  values  provided  by  the  match  in  place  of  the  indicated 
skeleton  variables. 

In  all,  about  30  rules  such  as  the  ones  in  figure  11  suffice  to  produce  an 
algebraic  simplifier  that  operates  on  expressions  represented  using  Lisp-style 
prefix  notation.  Having  created  the  rule  language,  we  can  apply  it  to  other 
problems  as  well  by  specifying  other  sets  of  rules.  For  example,  we  could  do 
algebraic  simplification  using  some  other  syntax  for  algebraic  expressions,  or 
we  could  build  a  peephole  optimizer  for  a  compiler  by  specifying  a  collection 
of  rules  that  reduce  specified  sequences  of  computer  instructions  to  more 
efficient,  equivalent  sequences. 

3.2  The  rule  interpreter 

Programming  a  simplifier  in  the  rule  language  allows  us  to  focus  on  the  rules 
themselves,  without  becoming  distracted  by  concerns  about  the  strategy  and 
mechanism  by  which  rules  are  applied.  These  issues  are  faced  by  the  rule 
interpreter. 

Given  a  list  of  rules,  make-simplifier,  shown  in  figure  12,  returns  a 
simplification  procedure  that  applies  these  rules.  This  procedure  embodies 
a  rule-application  strategy  whereby  rules  are  repeatedly  applied  until  the 
expression  is  unchanged.  Using  this  strategy  with  a  set  of  arbitrary  rules 
can  be  dangerous — the  rule  application  process  may  not  terminate,  or  the 
result  of  applying  the  rules  may  not  be  well-defined.  With  this  strategy,  we 
must  be  careful  to  propose  rules  that  yield  a  reduction  process — one  that  will 
eventually  terminate  with  a  canonical  form. 

The  mechanism  of  rule  application  is  implemented  by  try-rules,  which 
is  shown  in  figure  13.  The  pattern- matcher  used  by  try-rules  (see  fig¬ 
ures  14,  15,  and  16)  is  written  in  continuation-passing  style.  In  this  style, 
a  procedure  is  passed  continuation  procedures  that  are  to  be  called  when 
the  procedure  is  done.  Continuation-passing  style  can  be  used  to  implement 
many  sophisticated  program  control  structures.  The  matcher  exploits  con¬ 
tinuation  style  to  implement  the  backtracking  required  to  handle  segment 
variables. 

The  difficulty  with  segment  variables  is  that  they  allow  a  pattern  to  match 


a  given  data  item  in  more  than  one  way.  For  example,  the  pattern 

((??  x)  (??  y)  (??  x)  (??  z)) 

can  be  matched  against  the  expression 

(1  2  3  1  2  3  1  2  3) 

to  give  the  dictionary 

x  :  (1) 
y  :  (2  3) 
z  :  (23123) 

or  the  dictionary 

x  :  (1  2) 
y  :  (3) 
z  :  (3123) 

or  the  dictionary 

x  :  (12  3) 

y  :  (  ) 

z  :  (123) 

or  13  other  possible  dictionaries. 

One  way  to  handle  such  multiple  matches  is  to  design  the  matcher  so  that 
it  returns  a  list  of  all  possible  dictionaries  that  could  complete  the  match. 
But  this  would  be  very  inefficient — for  a  complex  pattern  there  could  easily 
be  thousands  of  possibilities  and  there  is  no  need  to  generate  them  all.  An 
alternative  idea  is  to  have  the  matcher  generate  a  single  dictionary  to  be  used 
by  the  rule  interpreter,  together  with  a  way  to  go  back  and  generate  more 
possibilities  if  the  first  one  proves  to  be  unsuitable,  for  example,  if  the  values 
in  the  dictionary  turn  out  not  to  satisfy  the  rule  predicate.  The  strategy  of 
returning  to  a  previous  choice  point  in  a  program  to  try  more  possibilities  is 
called  backtracking.  While  there  are  many  ways  to  implement  backtracking, 
continuation  passing  fills  the  need  nicely,  because  the  “place  to  go  back  to” 
can  be  embedded  in  the  failure  continuation. 


Figure  16  shows  the  procedure  segment-match,  which  uses  continuations 
to  implement  backtracking  in  this  way.  Where  there  is  no  value  for  the 
pattern  variable  already  in  the  dictionary,  the  matcher  is  free  to  bind  the 
segment  variable  to  any  initial  segment  of  the  datum.  The  choice  is  made 
using  the  internal  procedure  try-segment,  whose  argument  is  the  rest  of 
the  data  after  the  segment  to  be  tried.  The  success  continuation  for  this 
choice  is  the  same  as  for  the  original  call.  The  failure  continuation  reruns 
try-segment  choosing  a  longer  initial  segment.  Successive  failures  will  try 
longer  and  longer  segments  until  either  the  match  succeeds  or  the  data  runs 
out  and  the  original  fail  continuation  is  invoked. 

3.3  Memoizing  to  avoiding  redundant  computation 

If  a  subexpression  appears  in  an  expression  more  than  once,  the  rule-interpreter 
will  go  through  the  work  of  simplifying  the  expression  each  time  it  appears. 

For  example,  in  simplifying  (+  (*  x  2  y)  (*  x  2  y)),  the  subexpression 
(*  x  2  y)  is  simplified  twice.  Such  redundancy  is  typical  of  programs  that 
use  recursive  decomposition.  Perhaps  the  best-known  example  of  this  phe-  ^»r- 

nomenon  is  in  computing  the  Fibonacci  numbers  using  the  recurrence  rela¬ 
tion: 

{0  if  n  =  0 

1  if  n  =  1 

Fib(n  —  1)  +  Fib(n  —  2)  if  n  >  2 

Interpreting  this  recurrence  as  a  recursive  procedure  leads  to  a  process  in 
which  the  time  required  to  compute  Fib(n)  grows  exponentially  with  n,  due 
to  the  redundant  computations. 

One  could  implement  another  algorithm  for  computing  Fibonacci  num¬ 
bers,  or  make  ad  hoc  modifications  to  the  rule  interpreter’s  control  structure. 

However,  there  is  a  technique  for  dealing  with  this  problem  in  a  uniform  way 
by  using  memoized  procedures.  A  memoized  procedure  maintains  a  history  of 
the  values  it  has  been  asked  to  compute.  When  asked  to  compute  a  value,  the 
procedure  first  checks  to  see  if  that  value  has  already  been  computed.  If  so,  it 
returns  the  remembered  value  immediately.  If  not,  it  computes  the  value  and 
records  this  for  future  reference.  Figure  17  shows  a  higher-order  procedure 
memoize,  which,  given  a  procedure  f  as  argument,  returns  a  memoized  ver¬ 
sion  of  f .  The  memoized  version  of  f  is  called  in  the  same  way  that  f  is,  but 
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will  run  be  much  faster  because  it  avoids  redundant  computation.  Figure  18 
shows  the  make-simplifier  procedure  redefined  using  the  memoizer. 

Like  the  fixed-point  procedure  discussed  earlier,  memoize  expresses  a 
general  method  of  computing  as  a  higher-order  procedure.  Also,  as  with 
fixed-point,  the  power  of  this  approach  is  that  we  can  divide  programs 
into  meaningful  modules,  thus  separating  the  particular  task  of  simplifying 
expressions  or  computing  Fibonacci  numbers  from  the  general  strategy  of 
memoizing. 

4  Conclusion 

People  who  first  learn  about  Lisp  often  want  to  know  for  what  particular 
programming  problems  Lisp  is  “the  right  language.”  The  truth  is  that  Lisp 
is  not  the  right  language  for  any  particular  problem.  Rather,  Lisp  encour¬ 
ages  one  to  attack  a  new  problem  by  implementing  new  languages  tailored  to 
that  problem.  Such  a  language  might  embody  an  alternative  computational 
paradigm,  as  in  the  rule  language.  Or  it  might  be  a  collection  of  proce¬ 
dures  that  implement  new  primitives,  means  of  combination,  and  means  of 
abstraction  embedded  within  Lisp,  as  in  the  Henderson  drawing  language.  A 
linguistic  approach  to  design  is  an  essential  aspect  not  only  of  programming 
but  of  engineering  design  in  general.  Perhaps  that  is  why  Lisp,  although  the 
second-oldest  computer  language  in  widespread  use  today  (only  FORTRAN 
is  older),  still  seems  new  and  adaptable,  and  continues  to  accommodate  cur¬ 
rent  ideas  about  programming  methodology. 

5  A  note  on  Scheme 

Programming  languages  should  be  designed  not  by  piling  feature  on  top  of 
feature,  but  by  removing  the  weaknesses  and  restrictions  that  make  addi¬ 
tional  features  appear  necessary.  The  Scheme  dialect  of  Lisp  demonstrates 
that  a  very  small  number  of  rules  for  forming  expressions,  with  no  restric¬ 
tions  on  how  they  are  composed,  suffice  to  form  a  practical  and  efficient 
programming  language  that  is  flexible  enough  to  support  most  of  the  major 
programming  paradigms  in  use  today. 
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(define  (sqrt  x) 

(define  epsilon  1.0e-10) 

(define  (good-enough?  guess) 

(<  (abs  (-  (square  guess)  x)) 
epsilon) ) 

(define  (improve  guess) 

(average  guess  (/  x  guess))) 

(define  (try  guess) 

(if  (good-enough?  guess) 
guess 

(try  (improve  guess)))) 

(try  1)) 

Figure  1:  Scheme  is  a  block-structured  language,  incorporating  the  internal  definitions 
and  lexical  scoping  of  the  Algol  family  of  languages  into  a  modern  Lisp  dialect.  This 
simple  Scheme  procedure  computes  the  square  root  of  its  argument  using  the  method 
of  successive  averaging  attributed  to  Heron  of  Alexandria.  (Numerical  analysts:  Please 
forgive  us  for  the  end  test.) 


(define  (fixed-point  f  initial-value) 

(define  epsilon  1.0e-10) 

(define  (close-enough?  vl  v2) 

(<  (abs  (-  vl  v2) )  epsilon)) 

(define  (loop  value) 

(let  ((next-value  (f  value))) 

(if  (close-enough?  value  next-value) 
next -value 
(loop  next-value) ) ) ) 

(loop  initial-value)) 

(fixed-point  cos  1)  -->  .739085 

Figure  2:  This  procedure  implements  the  “boring  meeting”  method  of  finding  a  fixed 
point  of  a  function.  Note  the  use  of  this  procedure  to  find  a  fixed  point  of  cosine. 
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(define  (average-damp  f) 

(lambda  (x) 

(average  x  (f  x)))) 

(define  (sqrt  x) 

(fixed-point  (average-damp  (lambda  (y)  (/  x  y))) 

D) 


Figure  3:  Average-damp  is  a  procedure  that  takes  a  procedure  f  as  an  argument  and 
returns  a  procedure,  the  value  of  (lambda  (x)  . . .),  as  a  value.  Such  general  methods 
combine  to  allow  a  very  clear  description  of  Heron's  algorithm. 


(deline  diamond 

(let  ((*1  (vertex  0.5  0)) 
(v2  (vertex  1  0.5)) 
(v3  (vertex  0.6  1)) 
(v4  (vertex  0  0.5))) 
(priait ive-picture 
(list 

(segment  vl  v2) 
(segment  v2  v3) 
(segment  v3  v4) 
(segment  v4  vl))))) 


(define  leg 

(let  ((vl  (vertex  0.125  0)) 

(v2  (vertex  0.25  0)) 

(v3  (vertex  1  0.75)) 

(v4  (vertex  1  0.876)) 

(v5  (vertex  0.25  0.333)) 
(v8  (vertex  0.125  0.5))) 
(primitive-picture 
(list 

(segment  vl  v6) 
(segment  v6  v4) 
(segment  v3  v5) 
(segment  v6  v2))))) 


Figure  4:  At  the  lowest  level  of  description  in  Henderson’s  language,  pictures  are  specified 
as  collections  of  individual  geometric  elements.  Here  are  two  simple  pictures,  diamond  and 
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(define  (primitive-picture  segments) 

(lambda  (rect) 

(for-each 
(lambda  (segment) 

(drawline  ((point-map  rect)  (start-point  segment)) 

((point -map  rect)  (end-point  segment)))) 

segments))) 

Figure  5:  The  primitive-picture  procedure  takes  a  list  of  segments  and  produces  a 
picture.  A  segment  is  a  structure  from  which  we  can  extract  a  start  point  and  an  end 
point.  Drawline  is  a  procedure  that  draws  a  line  between  two  specified  points.  For-each 
takes  a  procedure  and  a  list  and  applies  the  procedure  consecutively  to  each  item  in  the 
list. 


(define  (point-map  rect) 

(lambda  (point) 

(♦vect  (scale-vector  (x-coordinate  point)  (bottom-edge  rect)) 
(scale-vector  (y-coordinate  point)  (left-edge  rect)) 
(origin  rect)))) 

Figure  6:  A  rectangle  is  a  data  structure  from  which  we  can  select  vectors  representing 
the  bottom  and  left  edges  of  the  rectangle  (that  is,  the  vectors  that  run  from  the  origin 
of  the  rectangle  to  the  lower  right  corner  and  to  the  upper  left  corner)  and  the  vector 
that  runs  from  the  origin  of  the  coordinate  space  to  the  origin  of  the  rectangle  Scheme, 
as  a  dialect  of  Lisp,  provides  list  operations  from  which  we  can  construct  compound 
data  objects  such  as  rectangles  and  vectors,  together  with  operations  on  compound  data 
objects,  such  as  vector  addition  and  scaling.  Point-aap  produces  a  transformation  that, 
for  a  given  rectangle,  maps  the  interior  of  the  unit  square  onto  the  interior  of  the  rectangle. 
The  transformed  image  of  a  point  (x,j/)  is  obtained  by  scaling  by  the  bottom  edge  by  x, 
the  left  edge  by  y,  and  summing  these  together  with  the  origin  vector. 


(define  legs  (beside  leg  (rotate90  leg)  0.3)) 

(define  (beside  pictl  pict2  ratio) 

(lambda  (rect) 

(pictl  (left-subrectangle  rect  ratio)) 

(pict2  (right-subrectangle  rect  ratio)))) 

Figure  7:  Here  is  a  compound  picture  formed  from  the  primitive  element  leg.  The 
picture  language  includes  geometric  combinators  for  adjoining  pictures  horizontally  and 
vertically,  and  for  rotating  pictures  by  90  degrees.  Beside  takes  two  pictures  and  a  ratio 
and  returns  the  procedure  that,  given  a  rectangle,  splits  the  rectangle  according  to  the 
ratio  into  right  and  left  subrectangles  and  draws  one  picture  in  each  part. 


(define  animal  (triangle  diamond  legs  0.3)) 

(define  (triangle  pictl  pict2  ratio) 

(above  pictl 

(beside  pict2  pict2  0.5) 
ratio)) 

Figure  8:  The  triangle  combinator  places  one  picture  above  two  copies  of  another.  We 
can  use  triangle  to  combine  diamond  and  legs 
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(right-push  leg  4  0.4) 

(define  (right-push  pict  n  ratio) 

(if  (*  n  0) 
pict 

(beside  pict 

(right-push  pict  (-  n  1)  ratio) 
ratio))) 


((push  triangle)  animal  3  0.5) 


(define  (push  combiner) 

(lambda  (pict  n  ratio) 

(define  (basic-combination  p) 

(combiner  pict  p  ratio)) 

((repeated-application  n  basic-combination)  pict))) 


(define  (repeated-application  n  operator) 

(if  (*  n  0) 

identity-operator 
(compose  operator 

(repeated-application  (-  n  1) 

operator)))) 


(define  (compose  f  g) 
(lambda  (x)  (f  (g  x)))) 


(define  identity-operator  (lambda  (x)  x)) 


Figure  10:  Puah  is  a  higher-order  combinator  that  transforms  rombinators  to  more 
elaborate  combinators.  The  helper  procedure  repeated-application  takes  a  positive 
integer  a  and  a  procedure  p  and  returns  the  procedure  that  applies  p  n  times. 
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Rule  1 : 


(  (-  (?  x)  (?  y))  ; pattern 

none  ; extra  condition 

(+  (:  x)  (*  -1  (:  y)))  )  ;skeleton 


Example:  (-  a  b)  — >  (+  a  (*  -1  b)) 


Rule  2:  (  (*  (??  a)  (+  (?  b)  (??  c))  (??  d)) 


uvuo 

(+  (*  (::  a)  (:  b)  (::  d))  (*  (::  a)  (+  (::  c))  (::  d)))  ) 


Example: 


(*  u  x  (+  p  q  r)  z)  — >  (+  (*  b  x  p  z)  (*  b  x  (♦  q  r)  z)) 


Rule  3:  (  (+  (?  cl  number?)  (?  c2  number?)  (??  s3)) 


(+  (:  (+  cl  c2))  (::  s3))  ) 


Example:  (+  3  4  x  y)  — >  (+  7  x  y) 


Rule  4: 


(  (*  (??  el)  (?  fl)  (??  s2)  (?  12)  (??  #3)) 

(same-base?  11  12) 

(*  (*  (:  (base  11))  (:  (+  (exponent  11)  (exponent  12)))) 
(::  si)  (::  s2)  (::  83))) 


Example : 


(*  a  (+  b  c)  (*  x  3)  y  C  x  4)  (*  z  2)) 
— >  (*  (“  x  7)  a  (+  b  c)  y  (*  z  2)) 


Figure  11:  Here  are  some  algebraic-simplification  rules  expressed  in  a  reduction-rule 
language,  together  with  examples  of  their  use.  Question  marks  in  patterns  denote  pattern 
variables.  The  pattern  in  rule  1  matches  any  list  of  three  elements  that  begins  with  a 
minus  sign.  The  colons  in  skeletons  indicate  that  the  corresponding  values  for  the  pattern 
variables  are  to  be  substituted  when  the  skeleton  is  instantiated.  Double  question  marks, 
as  in  rule  2,  denote  segment  variables — these  can  match  any  sequence  of  0  or  more  ele¬ 
ments.  Double  colons  in  skeletons  specify  that  the  segment  value  is  to  be  spliced  in  at  this 
position  during  instantiation.  Rule  3  illustrates  the  use  of  predicates  for  pattern  variables. 
Here  cl  and  c2  must  satify  the  number?  predicate.  In  general  a  pattern-variable  predicate 
can  be  any  Lisp  procedure.  Rule  4  uses  an  extra  condition  to  specify  that  factors  fl  and 
12  must  have  the  same  base  if  their  exponents  are  to  be  combined.  Observe  that  instanti¬ 
ating  the  skeletons  for  rules  3  and  4  requires  more  than  just  substitution — embedded  Lisp 
expressions  must  be  evaluated. 
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(define  (make-simplifier  the-rules) 

(define  (simplify-exp  exp) 

(let  ((result 

(try-rules  (if  (compound?  exp) 

(map  simplify-exp  exp) 
exp) 

the-rules))) 

(if  (equal?  result  exp) 
result 

(simplify-exp  result)))) 
simplify-exp) 

Figure  12:  Given  a  set  of  rules,  maka-simplif ier  produces  a  procedure  that  applies 
these  rules  to  expressions.  It  recursively  simplifies  every  subexpression  of  a  compound 
expression  and  simplifies  the  resulting  combination  of  the  simplified  parts.  Simplification 
is  iterated  until  the  expression  is  unchanged. 


(define  (try-rules  exp  the-rules) 

(define  (scan  rules) 

(if  (null?  rules) 
exp 

(match  (pattern  (car  rules))  exp  (make-empty-dictionary) 

; ;  procedure  to  call  if  the  match  fails 
(lambda  ()  (scan  (cdr  rules))) 

; ;  procedure  to  call  if  the  match  succeeds 
(lambda  (diet  fail) 

(if  (check-predicate  (rule-condition  (car  rules)) 

diet) 

(instantiate  (skeleton  (car  rules))  diet) 
(fail)))))) 

(scan  the-rules)) 


Figure  13:  Try-rules  performs  a  sequential  scan  through  the  rules,  using  a  pattern 
matcher  to  check  whether  a  rule  is  applicable.  Match  is  designed  to  be  called  with  five 
arguments — a  pattern,  an  expression,  a  dictionary  of  bindings  for  pattern  variables,  a 
procedure  to  be  executed  if  the  match  fails,  and  a  procedure  to  be  executed  if  the  match 
succeeds.  If  the  match  is  successful,  try-rules  checks  that  the  values  in  the  dictionary 
satisfy  the  rule’s  extra  conditions.  If  they  do,  the  dictionary  is  used  to  instantiate  the 
skeleton  part  of  the  rule.  This  is  returned  as  the  result  of  the  rule  application.  If  the 
dictionary  fails  the  extra  condition  test  try-rules  continues  just  as  if  the  match  had 
failed,  by  calling  the  fail  procedure. 
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(define  (match  pat  dat  diet  fail  succeed) 

(cond  ((eq?  pat  dat) 

(succeed  diet  fail)) 

((arbitrary-element?  pat) 

(element -match  pat  dat  diet  fail  succeed)) 

((constant?  pat) 

(if  (same-constant?  pat  dat)  (succeed  diet  fail)  (fail))) 
((start-arbitrary-segment?  pat) 

(segment -match  pat  dat  diet  fail  succeed)) 

((constant?  dat)  (fail)) 

(else 

(match  (car  pat)  (car  dat)  diet 
fail 

(lambda  (diet  fail) 

(match  (edr  pat)  (edr  dat)  diet 
fail 

succeed)))))) 


Figure  14.  Natch  is  a  recursive  comparison  that  proceeds  by  case  analysis.  Pattern 
variables  are  of  two  classes,  elements  and  segments,  handled  by  element-match  and 
segment— match.  If  the  pattern  and  the  datum  are  both  general  compound  expressions, 
match  calls  itself  recursively  to  match  the  first  element  of  the  pattern  against  the  first 
element  of  the  datum.  The  fail  continuation  for  this  sub-match  is  the  original  fail  con¬ 
tinuation.  If  the  sub-match  succeeds,  the  rest  (edr)  of  the  pattern  is  matched  against  the 
rest  of  the  datum  using  the  dictionary  produced  by  the  sub-match  and  the  continuations 
specified  for  the  original  match. 
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(define  (element-match  pat  dat  diet  fail  succeed) 

(let  ((vname  (var- name  pat))  (p  (var-restriction  pat))) 

(let  ((v  (lookup  vname  diet))) 

(if  (entry-exists?  v) 

(let  ((val  (element-in  v))) 

(if  (and  (equal?  val  dat) 

(apply-restriction  p  val)) 

(succeed  diet  fail) 

(fail))) 

(if  (apply-restriction  p  dat) 

(succeed  (extend-dictionary  vname  dat  diet)  fail) 
(fail)))))) 

Figure  15:  Element-match  takes  a  pattern  variable,  a  datum  to  match,  a  dictionary, 
and  fail  and  succeed  continuations.  If  there  is  already  an  entry  for  the  variable  in 
the  dictionary,  the  match  succeeds  if  the  value  in  the  entry  is  the  same  as  the  datum  to 
be  matched.  Otherwise  the  original  dictionary  is  extended  by  adding  a  binding  of  the 
pattern  variable  name  to  the  datum.  The  extended  dictionary  is  passed  to  the  succeed 
continuation. 
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(deline  (segment -match  pat  dat  diet  fail  succeed) 

(let  ((vname  (var-name  (car  pat)))  (p  (var-restriction  (car  pat)))) 
(let  ((v  (lookup  vname  diet))) 

(il  (entry-exists?  v) 

(let  ((val  (element-  in  v))) 

(il  (restrict-segment  p  val) 

(let  ((rest  (alter-initial-segment  val  dat))) 

(il  (not  (eq?  rest  ’no-initial-segment)) 

(match  (edr  pat)  rest  diet  lail  succeed) 
(fail))) 

(fail))) 

^lat  ^  Ito  permit  internal  delinition 

(deline  (try-segment  rest) 

(deline  (try-longer-segment) 

(il  (null?  rest)  (lail)  (try-segment  (edr  rest)))) 

(il  (restrict-segment  p  (make-segment  dat  rest)) 

(match  (edr  pat) 
rest 


(extend-dictionary  vname 

(make-segment  dat  rest) 
diet) 

try-longer-segment 

succeed) 

(try-longer-segment))) 

(try-segment  dat)))))) 


F  igure  16:  The  procedure  that  handles  segment  matching  implements  backtracking 
via  a  failure  continuation  that  tries  successively  longer  segments.  The  utility  procedure 
alter-initial-segment  returns  the  rest  of  the  datum  after  a  given  initial  segment,  or 
notes  that  the  initial  segment  of  the  datum  does  not  match  the  desired  segment. 


(define  (memoize  f) 

(let  ((table  (empty-table))) 

(lambda  (x) 

(let  ((seen  (lookup-in-table  x  table))) 

(if  (valid-table-entry?  seen) 

(table-entry-value  seen) 

(let  ((ans  (f  x))) 

(insert-in-table!  table  (make-table-entry  x  ans)) 
ans)))))) 

(define  fib 
(memoize 
(lambda  (n) 

(cond  ((*>  n  0)  0) 

((-  n  1)  1) 

(else  (+  (fib  (-  n  1))  (fib  (-  n  2)))))))) 

Figure  1 7 :  Memoize  is  a  higher-order  procedure  that  transforms  its  argument  procedure  f 
into  a  new  procedure  that  computes  the  same  result,  only  avoiding  redundant  computation. 
The  recursive  fib  procedure  uses  the  memoizer  to  compute  (fib  n)  in  time  proportional 


if- 


Cdafine  (make-simplifier  the-rules) 

(define  simplify-exp 
(memoize 
(lambda  (exp) 

(let  ((result 

(try-rules  (if  (compound?  exp) 

(map  simplify-exp  exp) 
exp) 

the-rules))) 

(if  (equal?  result  exp) 
result 

(simplify-exp  result)))))) 
simplify-exp) 


Figure  18:  Mernoizing  the  simplifier  can  greatly  improve  the  performance  of  the  rule 
interpreter. 


